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Abstract 

A  major  hurdle  in  sharing  resources  between  organiza¬ 
tions  is  heterogeneity.  Therefore,  in  order  for  two  organiza¬ 
tions  to  collaborate  their  policies  have  to  be  resolved.  The 
process  of  resolving  different  policies  is  known  as  policy 
reconciliation,  which  in  general  is  an  intractable  problem. 
This  paper  addresses  policy  reconciliation  in  the  context  of 
security.  We  present  a  formal  framework  and  hierarchical 
representation  for  security  policies.  Our  hierarchical  repre¬ 
sentation  exposes  the  structure  of  the  policies  and  leads  to 
an  efficient  reconciliation  algorithm.  We  also  demonstrate 
that  agent  preferences  for  security  mechanisms  can  be  read¬ 
ily  incorporated  into  our  framework.  We  have  implemented 
our  reconciliation  algorithm  in  a  library  called  the  Policy 
Reconciliation  Engine  or  PRE.  In  order  to  test  the  imple¬ 
mentation  and  measure  the  overhead  of  our  reconciliation 
algorithm,  we  have  integrated  PRE  into  a  distributed  high- 
throughput  system  called  Condor. 


1.  Introduction 

Security  policy  bridges  the  gap  between  static  imple¬ 
mentations  and  the  broad  and  diverse  security  requirements 
of  user  communities.  Security  policy  becomes  more  com¬ 
plicated  in  heterogeneous  environments.  When  two  or  more 
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entities  share  a  security  association,  they  must  reach  agree¬ 
ment  on  a  governing  policy  (e.g.,  two  end-points  in  an  IPsec 
session).  These  entities  express  their  requirements  for  the 
association  through  a  security  policy  (called  a  domain  pol¬ 
icy).  A  reconciliation  algorithm  finds  a  policy  that  is  con¬ 
sistent  with  all  domain  policies.  Where  a  consistent  policy 
can  be  found,  the  association  is  free  to  proceed.  Where  one 
cannot  be  found,  the  participants  must  alter  their  require¬ 
ments  or  abstain  from  participating. 

In  the  general  case,  policy  reconciliation  is  in¬ 
tractable  Q3  123).  As  a  result,  past  investigations  have 
largely  achieved  tractability  by  limiting  the  policy  represen¬ 
tation  or  by  using  heuristic  algorithms  (331 C3I [26] [33).  Such 
approaches  achieve  the  stated  goals,  but  fail  to  efficiently 
capture  dependencies  between  different  aspects  of  a  policy. 
Moreover,  these  systems  do  not  consider  preferential  policy 
i.e.,  it  is  advantageous  (and  often  necessary)  for  policy  not 
only  to  specify  what  is  legal  and  illegal,  but  to  state  what  is 
desirable. 

This  work  addresses  the  limitations  of  past  work  by 
developing  a  policy  framework  based  on  graphical  pol¬ 
icy  representations.  We  exploit  the  graph  representation 
to  efficiently  encode  the  complex  dependencies  inherent  to 
contemporary  policy.  We  formally  define  the  representa¬ 
tion  and  specify  an  efficient  preference  and  dependency- 
respecting  reconciliation  algorithm.  Before  introducing  our 
formalism,  we  present  an  overview  of  security  provisioning 
policy  and  the  intuition  behind  our  framework  in  the  follow¬ 
ing  section. 

1.1.  Security  Policy 

The  term  security  policy  has  come  to  mean  different 
things  to  different  communities.  For  example,  access  con¬ 
trol  policy  defines  who  has  access  to  what  and  under  what 
circumstances  fl[29l|30).  Other  forms  of  security  policy 
specify  under  what  conditions  credentials  are  accepted  (6), 
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or  how  a  firewall  is  configured  ED.  In  its  broadest  defini¬ 
tion,  security  policy  is  the  specification  of  security  relevant 
system  behavior.  This  paper  addresses  session-specific  con¬ 
figuration  of  security  services.  More  commonly  known  as 
security  provisioning  policy,  these  configurations  define  the 
guarantees  afforded  the  governed  environment  by  explicitly 
identifying  the  algorithms,  parameters,  and  protocols  used 
to  implement  security. 

To  illustrate  the  importance  and  ubiquity  of  security  pro¬ 
visioning  policy,  consider  an  email  client  (e.g.,  Netscape 
Communicator,  MS  Outlook).  A  user  specifies  a  provision¬ 
ing  policy  every  time  she  adds  an  account.  For  example, 
the  connection  method  (e.g.,  IMAP  over  SSL)  dictates  ex¬ 
actly  the  set  of  guarantees  you  will  receive  in  obtaining  and 
viewing  your  mail.  Note  that  the  decision  to  not  use  any  se¬ 
curity  service  is  still  a  specification  of  policy.  The  policies 
defined  for  the  applications  and  services  used  in  an  environ¬ 
ment  prescribe  the  security  afforded  its  users. 

In  practice,  provisioning  policy  is  more  complicated  than 
our  email  example  would  suggest.  It  is  often  important  that 
particular  organization-wide  goals  are  realized  in  the  many 
policies  implemented  by  the  environment.  Lower  level  poli¬ 
cies  must  be  constructed  such  that  they  are  compliant  with 
organizational  goals  l23l.  Moreover,  where  an  operation 
spans  organizations,  the  policies  of  each  organization  must 
be  reconciled  to  form  a  coherent  and  reasonable  policy. 

We  now  introduce  our  graphical  provisioning  policy  rep¬ 
resentation.  A  graphical  policy  is  a  series  of  policy  opera¬ 
tions  represented  by  cascading  circular  or  square  nodes  in 
a  singularly  rooted  directed  acyclic  graph  (DAG)  (formally 
this  structure  is  an  and-or  graph).  Policy  is  read  from  the 
root  node.  Each  node  may  be  a  decision  (circle)  or  a  collec¬ 
tion  (square).  A  decision  node  requires  that  exactly  one  of 


the  sub-graphs  emanating  from  the  node  be  resolved,  and  a 
collection  node  requires  all  sub-graphs  be  resolved.  All  leaf 
nodes  are  added  to  the  policy.  Any  configuration  derived 
from  a  policy  respects  these  two  simple  rules. 

Figure  [T]  shows  a  graphical  provisioning  policy  for  key 
management  used  in  an  IPsec  VPN.  This  policy  would  be 
specified  by  a  user  or  network  administrator  as  part  of,  for 
example,  VPN  setup.  One  reads  the  example  policy’s  root 
(decision  node)  as: 

(configure)  Preshare  (preshareed  keys)  or  IKE 
The  right-hand  side  of  the  graph  (IKE,  from  the  root)  de¬ 
picts  a  complex  series  of  configurations  used  to  specify  the 
behavior  of  the  Internet  Key  Exchange  (IKE)  protocol  m. 
The  IKE  sub-policy  consists  of  three  independent  configu¬ 
rations.  We  read  the  top  IKE  (collection  node)  as: 

(configure)  DH  group  and  HMAC  and  Encryption 
The  remainder  of  the  policy  is  read  as  a  selection  of  a  sin¬ 
gle  DH  group,  a  hashing  algorithm,  and  an  encryption  al¬ 
gorithm.  Independent  of  the  encryption  algorithm,  a  mode 
(e.g.,  CBC)  must  be  selected.  Moreover,  this  policy  man¬ 
dates  the  use  of  CBC  mode. 

The  example  policy  is  used  at  the  point  at  which  an  end¬ 
point  (host)  is  connected  to  the  VPN.  The  policy  is  evalu¬ 
ated  by  identifying  a  subset  of  nodes  and  leaves  in  graph 
as  defined  by  the  structure  of  the  collection  and  decision 
nodes.  The  IPsec  implementation  uses  the  resulting  con¬ 
crete  specification,  called  an  evaluated  policy  or  instance, 
to  implement  the  IPsec  session.  For  example,  one  possible 
evaluated  policy  contains:  IKE,  DH-Group  2,  HMAC-MD5, 
IDEA-CBC. 

Two  important  factors  are  highlighted  by  this  example. 
First,  this  is  one  of  many  possible  policies  for  IPsec  key 
management.  Depending  on  the  goals  of  the  specified  pol¬ 
icy,  the  specifier  may  structure  the  policy  in  a  number  of 
different  ways.  For  example,  inasmuch  as  it  is  consistent 
with  the  IPsec  implementation,  the  policy  can  allow  other 
encryption  modes  (e.g.,  ECB)  by  adding  an  additional  deci¬ 
sion  node. 

The  second  factor  of  note  is  that  unlike  our  email  policy, 
this  policy  specifies  a  range  of  behaviors.  That  is,  the  policy 
states  that  there  are  a  set  of  configurations  that  are  equally 
acceptable.  The  structure  of  the  graph  directly  mandates 
which  sets  of  configurations  should  be  considered  accept¬ 
able.  Having  non-prescriptive  policies  allow  the  environ¬ 
ment  to  make  performance  and  security  trade-offs  at  run 
time,  and  is  essential  to  reconciling  policies  from  different 
domains. 

Now  consider  the  case  where  there  is  not  a  single  source 
of  policy:  for  example,  where  the  end-points  of  the  VPN  lie 
in  different  administrative  domains.  Each  domain  wishes  to 
exert  control  over  the  session  as  specified  through  a  domain 
policy  (e.g.,  similar  to  Figure  [lj.  Hence,  the  two  parties 
must  find  an  evaluated  policy  that  is  consistent  with  the  do- 


main  policies  supplied  by  both.  This  is  performed  by  rec¬ 
onciling  the  domain  policies.  The  session  can  continue  only 
where  a  single  governing  policy  can  be  found.  If  not,  the  do¬ 
main  policies  are  incompatible  and  the  end-points  must  alter 
their  policies  or  refrain  from  participating  in  the  session. 

The  study  of  provisioning  policy  is  unlike  other  policy 
efforts  in  several  ways.  First  and  most  obviously,  provi¬ 
sioning  policy  is  a  planning  process.  Traditional  autho¬ 
rization  policy  systems  determine  whether  a  particular  ac¬ 
cess  is  legal  with  respect  to  some  larger  governing  policy. 
Conversely,  provisioning  policy  attempts  to  find  some  con¬ 
figuration  that  is  consistent  with  a  governing  provisioning 
policy. 

Provisioning  policy  also  embodies  complex  dependen¬ 
cies.  That  is,  decisions  about  particular  aspects  of  the  policy 
affect  subsequent  options.  Figure  [T|  illustrates  a  very  sim¬ 
ple  dependency:  the  decision  to  use  IKE  over  pre-shared 
keys  has  enormous  impact  on  the  further  development  of 
policy.  The  selection  of  IKE  leads  to  decisions  concern¬ 
ing  the  kinds  of  Diffie-Hellman  groups  to  use,  what  encryp¬ 
tion  algorithms  are  necessary,  etc.  However,  if  pre-shared 
keys  were  selected,  other  configuration  values  (e.g.,  Diffie- 
Hellman  group)  should  and  would  not  be  considered. 

Provisioning  is  also  subject  to  preferential  behavior. 
That  is,  there  is  a  often  a  set  of  configurations  that  is  most 
desired  among  several  choices.  Again  consider  Figure  [T] 
According  to  the  policy,  either  group  1  or  group  2  is  ac¬ 
ceptable.  In  practice,  we  have  found  the  vast  majority  of 
IPsec  configurations  use  group  2.  As  such,  we  (rightly  or 
wrongly)  may  decide  that  group  2  is  best  for  our  environ¬ 
ment,  and  is  thus  preferred.  However,  for  compatibility  rea¬ 
sons,  we  do  not  wish  to  preclude  the  use  of  group  1 .  Note 
that  preferential  configurations  are  more  than  simple  default 
values,  but  a  partial  ordering  of  the  available  options.  The 
existence  of  preferences  is  largely  ignored  by  previous  work 
in  this  area. 

As  we  demonstrate  in  the  following  sections,  reconcilia¬ 
tion  is  made  more  complex  by  the  introduction/appreciation 
of  these  deeper  aspects  of  policy.  While  this  work  aspires  to 
provide  intuitive  policy  representations,  it  must  do  so  within 
the  constraints  of  these  new  complex  semantics.  Hence,  our 
contribution  lies  not  only  in  the  representation  or  added  se¬ 
mantics,  but  in  the  successful  marriage  of  the  two. 

1.2.  Contributions 

This  paper  addresses  the  aforementioned  deficiencies  of 
existing  systems  by  modeling  dependencies  and  preferences 
in  a  graphical  policy  framework.  The  main  contributions  of 
this  paper  are: 

•Graph-based  provisioning  policy  (exposes  dependen¬ 
cies):  We  present  a  model  that  represents  policies  as  di¬ 
rected  acyclic  graphs  (DAG).  This  model  captures  de¬ 
pendencies  between  policy  components  within  a  schema. 


Hence,  because  policies  adhere  to  the  schema,  it  is  impossi¬ 
ble  to  define  a  correctly  formed  policy  that  is  not  consistent 
with  the  dependencies. 

•Efficient  reconciliation:  In  general,  policy  reconciliation 
is  iVP-complete  1231 .  However,  a  graphical  representation 
of  policies  expose  their  structure  and  present  a  basis  for  an 
efficient  reconciliation  algorithm.  We  provide  an  efficient 
reconciliation  algorithm  for  our  graphical  model.  Our  rec¬ 
onciliation  algorithm  is  linear  in  the  size  of  the  policies. 

•Preferential  policy:  Participant  preferences,  such  as  a 
server’s  preferences  for  authentication  mechanisms,  can  be 
incorporated  into  our  model.  An  important  problem  that 
arises  in  this  context,  is  that  of  resolving  multiple  partial 
orders  on  the  same  set  (intuitively,  these  partial  orders  rep¬ 
resent  preferences  of  different  participants).  We  provide  an 
efficient  algorithm  to  resolve  multiple  partial  orders  and  ex¬ 
tend  the  reconciliation  algorithm  to  handle  preferences. 

•Implementation  and  deployment:  Based  on  our  hierar¬ 
chical  framework,  we  have  implemented  a  reconciliation 
module  called  the  Policy  Reconciliation  Engine  or  PRE, 
which  is  available  for  download.  We  have  integrated  PRE 
with  Condor  ED,  a  high-throughput  scheduling  system 
used  to  manage  resources  in  a  complex  distributed  environ¬ 
ment.  We  show  experimentally  that  the  cost  of  reconcilia¬ 
tion  is  negligible. 

2.  Related  Work 

Other  policy  systems.  Historically,  policy  systems  have 
not  addressed  reconciliation.  For  example,  trust  manage¬ 
ment  systems,  such  as  KeyNote  J5),  SPKI/SDSI  II 121 II 31. 
Binder  iflOl.  and  SD3  lfl8l  are  concerned  with  compliance 
checking  rather  than  reconciliation.  In  trust  management 
systems,  policies,  called  credentials,  are  simply  crypto¬ 
graphic  proofs  that  express  authorization  delegation.  The 
compliance  checker  algorithm  searches  the  available  cre¬ 
dentials  for  an  accepting  delegation  chain  that  satisfies  a 
specific  request.  Credentials  can  state  a  set  of  provision¬ 
ing  requirements.  An  action  is  only  allowed  where  the  pro¬ 
visioning  of  the  environment  matches  the  credential.  Such 
approaches  are  useful  for  managing  policy  in  a  widely  de¬ 
ployed  or  loosely  organized  environments  S3-  However, 
because  credentials  mandate  provisioning,  there  is  no  op¬ 
portunity  to  perform  reconciliation.  Other  systems  simply 
assume  a  singular  entity  manually  performs  reconciliation 
when  issuing  policy  for  a  domain  0. 

Hardness  of  reconciliation.  While  reconciliation  has 
only  recently  begun  to  be  explored,  the  policy  community 
has  already  developed  a  broad  characterization  of  the  prob¬ 
lem.  Gong  and  Qian  discovered  that  reconciliation  of  autho¬ 
rization  policy  (in  their  work,  called  policy  composition)  is 


NP-complete  lfl5l.  Similarly,  the  authors  of  Ismene  found 
that  reconciliation  of  general  purpose  provisioning  policy 
is  also  NP-complete  (23).  Such  results  do  not  mean  that 
progress  cannot  be  made,  but  suggests  a  required  shift  in 
the  goals  of  investigation.  Much  of  the  ongoing  work  in 
reconciliation  has  centered  on  techniques  that  alter  the  envi¬ 
ronment  or  restrict  policy  to  obtain  efficient  reconciliation. 
However,  our  paper  demonstrates  that  by  using  a  represen¬ 
tation  that  exposes  structure  of  the  policies,  the  reconcilia¬ 
tion  problem  becomes  tractable  for  a  larger  class  of  policies. 

Other  reconciliation  approaches.  One  way  to  address 
the  inherent  complexity  of  reconciliation  is  by  essentially 
“flattening”  the  policy  representation,  i.e.,  explicitly  enu¬ 
merating  the  various  choices.  For  example,  the  IPsec  Secu¬ 
rity  Policy  System  (SPS)  (33l  guarantees  efficient  two-party 
reconciliation  by  intersecting  fixed  and  independent  sets  of 
policy  values.  The  DCCM  system  extends  this  approach  to 
the  multi-party  environments  by  providing  a  Chinese  menu 
reconciliation  algorithm  mmin  i.  Each  participant  chooses 
values  from  a  fixed  set  of  policy  dimensions  (e.g.,  one  from 
column  A,  two  from  column,  B ,  etc  . . .).  The  policy  is 
reconcilable  where  an  intersection  of  proposals  is  found  for 
each  dimension.  Conflicts  (where  no  such  intersection  is 
found)  are  resolved  by  an  unspecified  algorithm. 

A  limitation  of  both  SPS  and  DCCM  is  that  they  as¬ 
sume  that  there  are  no  dependencies  between  policy  values. 
For  example,  in  an  IPsec  policy,  an  encryption  algorithm 
is  needed  when  the  ESP  transform  is  selected.  Therefore, 
to  ensure  that  the  resulting  policy  is  enforceable,  one  must 
disallow  any  policy  that  defines  the  ESP  transform  but  no 
encryption  algorithm.  In  practice,  these  systems  define  pol¬ 
icy  as  an  enumeration  of  legal  policy  combinations,  such 
as  ESP-3DES-HMAC-SHA.  Since  only  legal  enumerations 
are  available,  no  dependency  can  be  violated.  However, 
the  number  of  enumeration  values  grows  exponentially  in 
the  size  of  the  domains,  and  therefore  the  “enumeration  ap¬ 
proach”  is  inherently  not  scalable. 

Ismene  policies  are  defined  as  expressions  of  provision¬ 
ing  variables  (23l.  The  reconciliation  algorithm  tries  to  find 
a  satisfying  truth  assignment  for  the  universe  of  provision¬ 
ing  variables.  Reconciliation  is  cast  as  an  instance  of  sat¬ 
isfaction  (over  the  conjunction  of  policy  proposals).  Effi¬ 
ciency  is  guaranteed  by  using  a  pair-wise  satisfaction  algo¬ 
rithm  on  restricted  policy  expressions.  The  iterative  Ismene 
n-policy  reconciliation  algorithm  is  sound  but  not  complete, 
i.e.,  some  collections  of  reconcilable  policies  may  be  re¬ 
jected.  Furthermore,  like  SPS,  the  Ismene  reconciliation  al¬ 
gorithm  does  not  consider  dependencies.  Dependencies  are 
addressed  in  Ismene  by  evaluating  the  reconciliation  result 
with  respect  to  a  set  of  “correctness  rules”  using  an  analysis 
algorithm.  This  approach  is  limited  in  that  it  occurs  after 
the  policy  has  been  identified.  Hence,  reconciliation  must 
be  re-performed  after  each  policy  is  rejected  by  analysis. 


BANDS  (32l  addresses  multi-domain  policy  reconcilia¬ 
tion  in  the  context  of  IPsec  by  describing  the  security  re¬ 
quirements  of  each  domain  in  a  policy  language  Ifl4l.  The 
provisioning  policy  between  two  nodes  (source  and  desti¬ 
nation)  is  proposed  by  the  source  node  through  a  gathering 
phase  where  security  requirements  from  all  domains  along 
the  path  are  gathered.  From  the  gathered  requirements,  a 
policy  is  then  proposed  and  passed  along  the  path  to  the 
destination  node.  Each  domain  along  the  path  must  verify 
the  policy  against  its  own  security  requirements  or  return  an 
error  to  the  source  node.  If  the  proposed  policy  reaches  the 
destination  node  without  an  error,  it  becomes  the  provision¬ 
ing  policy  for  the  session. 

A  central  limitation  of  the  approaches  defined  above  is 
that  they  are  not  sensitive  to  the  structure  of  policy.  Depen¬ 
dencies  between  different  aspects  of  policy  are  either  inef¬ 
ficiently  encoded  or  externally  evaluated.  This  is  a  prime 
motivation  of  the  current  work.  Dependencies  are  captured 
through  the  graphical  structure  of  the  policy  schema,  and 
hence  any  policy  resulting  from  reconciliation  is  guaranteed 
to  be  consistent  with  these  dependencies.  Previous  reconcil¬ 
iation  algorithms  also  make  no  distinction  between  recon¬ 
ciliation  results.  Since  no  distinction  is  made,  every  possi¬ 
ble  result  is  equally  desirable.  However,  environments  often 
desire  to  specify  default  behavior  and  allow  others  where 
the  defaults  are  inefficient  or  infeasible.  This  work  allows 
such  desires  to  be  expressed  through  preferences. 

Other  work  on  representation  and  analysis  of  security 
policies.  Cholvy  and  Cuppens  consider  the  complexities 
of  detecting  and  managing  inconsistencies  introduced  by 
access  control  policy  specifications  (5).  Our  approach  dif¬ 
fers  not  only  in  problem  domain  (i.e.,  provisioning),  but  in 
that  we  avoid  consistency  evaluation  by  encoding  depen¬ 
dencies  within  the  policy  structure.  Hence,  collections  of 
individual  policies  cannot  be  inconsistent.  Cholvy  and  Cup- 
pens  further  considered  preference  in  the  context  of  the  or¬ 
dered  application  of  access  control  regulations,  but  focused 
on  access  control  applications. 

While  it  has  not  been  explored  for  other  forms  of  policy, 
graphical  representations  are  well  suited  to  access  control 
policy  (2011251.  For  example,  the  LaSCO  language  specifies 
access  control  policy  using  graphical  idioms  liTTl.  The  de¬ 
velopers  of  LaSCO  assert  that  the  representation  allows  not 
only  specification  a  more  intuitive  operation,  but  permits  the 
use  of  well  known  graph  algorithms  for  subsequent  enforce¬ 
ment.  We  embrace  a  similar  approach  by  using  structural 
representation  to  enforce  dependencies. 

3.  A  Formalization  of  Policy  Reconciliation 

In  this  section  we  provide  a  precise  semantics  of  policy 
reconciliation  where  the  policies  are  represented  hierarchi¬ 
cally.  Moreover,  we  describe  how  preferences  can  be  incor- 
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Figure  2.  Schemata  S 

porated  into  our  framework.  Finally,  we  present  an  efficient 
reconciliation  algorithm. 

Definition  3.1  A  schemata  is  a  directed  acyclic  graph  or 
DAG  S  =  ( N,E ,  root),  where  TV  is  a  set  of  nodes,  E  C 
TV  x  TV  is  a  set  of  edges,  and  root  £  TV  is  a  distinguished 
node.  We  assume  that  root  has  no  incoming  edge.  Each 
node  n  has  the  following  attributes  associated  with  it: 

•  Each  node  is  a  A  or  V  node. 

•  A  tuple  of  variables  (denoted  by  Varrin ))  (Vi  : 
Ti,  ■  •  • ,  Vfe  :  Tfc)  (where  t,  is  the  type  of  variable  Vi). 
Currently,  we  only  allow  types  string,  int,  real, 
and  enum.  For  an  enuin  type  Ti  we  assume  that  a  set  of 
values  is  given,  e.g.,  Ti  =  {DES,  3DES,  AES}. 

The  set  of  successors  of  a  node  n  in  a  schemata  S  is  denoted 
by  succs(n).  However,  when  the  schemata  S  is  clear  from 
the  context  we  simply  write  succ(n)  instead  of  succs(n). 

A  schemata  is  shown  in  Figure  [2]  The  root  node  is  a  A- 
node  and  represented  as  a  square.  The  left  and  right  child 
of  the  root  are  V-nodes  and  represent  various  authentication 
and  encryption  mechanisms  respectively.  The  leaf  nodes, 
such  as  the  ones  labeled  with  none  and  3DES,  are  V-nodes 
with  no  successors.  The  special  keyword  none  signifies  the 
fact  that  an  authentication  or  encryption  scheme  is  not  re¬ 
quired.  Moreover,  there  are  no  variables  associated  with  the 
V-nodes.  However,  if  desired,  associated  attributes,  such  as 
key  size  for  encryption  schemes,  can  be  associated  with  the 
V-nodes. 

Definition  3.2  An  instance  I  of  a  schemata  S  = 
(TV,  V,  root)  is  a  subgraph  (AT7,  V' ,  root),  where  TV7  C  TV 
and  V 7  C  V.  Additionally,  following  conditions  need  to  be 
satisfied: 

•  For  a  A-node  n  £  TV7,  succ[n)  C  TV7.  In  other  words, 
all  successors  of  a  A-node  are  in  the  instance  I. 

•  For  a  V-node  n  £  TV7,  if  succ(n)  is  non-empty,  then 
|  succ(n)  ITTV'I  =  1.  In  other  words,  for  a  V-node  with 
a  non-empty  set  of  successors,  exactly  one  successor 
is  in  an  instance. 


•  Consider  a  node  n  £  N’  such  that  Varrin)  =  (Vi  : 
ti,  •  •  • ,  14  :  Tfc).  In  this  case,  I  assigns  values  vl  of 
type  Ti  to  each  variable  Vj  in  Var'r(n).  The  tuple 
of  values  assigned  by  /  to  the  node  n  is  denoted  by 
Vali(n). 

Definition  3.3  A  policy  P  for  a  schemata  S  =  ( TV ,  V,  root) 
is  a  2-tuple  (S,  C),  where  S  :  N  —>  2N  and  C  maps  nodes 
to  a  tuple  of  conditions.  For  each  V-node  n  £  N,  S(n)  C 
succ(n),  and  C(n )  is  a  /c-tuple  of  conditions  (ci,  •  •  •  ,Ck) 
where  Var(n )  =  ( V\  :  ri ,  •  •  • ,  V}  :  t>).  Moreover,  we 
assume  that  the  condition  c,  applies  to  values  of  type  r,. 
Given  a  value  v-L  of  type  rt,  we  use  Vi  |=  c*  to  denote  that  Vi 
satisfies  Cj. 

Two  policies  P\  and  P2  are  shown  in  figures [3]and [4] re¬ 
spectively.  Consider  the  left  child  of  the  root.  Policy  P\ 
specifies  that  only  X509,  Kerberos,  and  Password  are  al¬ 
lowed  successors  for  the  left  node.  Other  edges  and  nodes 
can  be  interpreted  in  a  similar  manner. 

Given  an  instance  /  =  (TV7,  V' ,  root)  and  a  policy  P  = 
(S,  C),  we  say  that  /  satisfies  P  (denoted  by  I  \=  P)  iff  the 
following  two  conditions  are  satisfied: 

•  For  all  V-nodes  n  £  N',  (succ(n)  IT  TV7)  C  S(n).  In 
other  words,  instance  I  can  only  choose  successors  of 
a  V-node  from  the  subset  S(n)  provided  by  the  policy 

P. 

•  Fet  Vali[n)  =  {v\ ,  •  •  • ,  Vk)  be  the  values  assigned  to 
the  node  n  in  I,  and  C(n)  =  (ci,  •  •  • ,  Cfc)  be  the  condi¬ 
tions  assigned  to  node  n  by  the  policy  P.  In  this  case, 
for  1  <  i  <  k,  Vi  |=  Ci,  or  each  value  assigned  in  the 
instance  /  should  satisfy  the  corresponding  condition 
specified  by  the  policy  P. 

Policy  P  for  a  schemata  S  is  called  satisfiable  iff  there  exists 
I  such  that  I  \=  P. 

Next,  we  define  conjunction  of  two  policies.  The  con¬ 
junction  of  two  policies  Pi  =  (Si,  Ci)  and  P2  =  (S2,  C-fi) 
(denoted  by  Pi  A  P2)  is  a  policy  (S' ,  C'),  where 

•  For  each  V-node  n  £  TV,  S7(n)  =  Si(n)  IT  S2(n) 
and  C'(n )  =  (c|  A  c?,  ■  ■  • ,  cl  A  cl),  where  CHn)  = 
(c},-",4)  and  C2(n)  =  (c\,---,c2k). 

Conjunction  of  the  two  example  policies  Pi  and  P2  is  de¬ 
picted  in  Figure  [5] 

Definition  3.4  A  set  of  n  policies  Pi,  •  •  • ,  Pn  is  reconcil¬ 
able  iff  there  exists  an  instance  I  such  that  /  |=  (A"=i  -Ai) 
or  in  other  words  /\)Li  A  *s  satisfiable. 

Remark:  We  have  described  the  semantics  of  reconcilable 
policies  using  the  satisfaction  relation  |=.  One  can  give  an 
alternative  definition  in  terms  of  languages.  A  schemata  S 


defines  a  language  of  instances  L(S),  i.e.,  L(S )  contains  all 
instances  I  of  the  schemata  I.  A  policy  P  for  the  schemata 
S  also  defines  a  language  of  instances  L(P)  C  L(S),  i.e., 
L(P)  contains  all  instances  /  such  that  I  \=  P.  In  this 
context,  policies  Pi,  ■  ■  ■ ,  Pn  are  reconcilable  iff  |"|™  L(Pf) 
is  non-empty. 

3.1.  Resolving  multiple  partial  orders 

Later  in  this  section  we  discuss  policy  reconciliation  in 
presence  of  preferences.  In  preparation  for  that,  we  need 
to  develop  some  theory  about  resolving  multiple  partial  or¬ 
ders.  Assume  that  we  are  given  a  finite  set  S.  Suppose 
n  agents  give  their  preferences  on  the  set  S,  i.e.,  agent  i 
specifies  a  partial  order  Aj  on  the  set  S.  Intuitively,  an 
agent  i  is  an  organization  or  process  with  a  policy,  and  A, 
specifies  the  preference  of  the  organization  or  process.  The 
question  is  how  does  one  construct  a  single  partial  order 
on  the  set  S  (denoted  by  —  1,  —  ,n)  from  the  n  partial  orders 
—  1 3  '  '  '  3  — rA*  Precise  definition  for  combining  partial  or¬ 
ders  is  given  in  0T1.  We  also  provide  a  a  linear  time  algo¬ 
rithm  to  compute  the  combined  partial  order.  For  example, 
consider  two  partial  orders  shown  in  Figure  [6]  on  the  set 
{Kerberos,  X509,  Password  }.  Assuming  that  the 
agent  giving  the  partial  order  (a)  has  higher  preference  than 
the  agent  with  the  partial  order  (b),  the  combined  partial  or¬ 
der  is  (b).  Assuming  no  order  between  the  agents  the  com¬ 
bined  partial  order  is  (a). 

3.2.  Reconciliation  with  preferences 

This  section  describes  reconciliation  when  policies  are 
allowed  to  specify  preferences.  First,  we  define  the  concept 
of  policy  with  preferences. 

Definition  3.5  A  policy  P  for  a  schemata  S  =  ( N ,  V,  root) 
is  now  a  3-tuple  ( S ,  C ,  pref),  where  S  :  N  — »  2N ,  C  maps 
nodes  to  a  tuple  of  conditions,  and  pref  provides  prefer¬ 
ences.  For  each  V-node  n  £  N,  S(n)  C  succ(n),  pref(n) 
is  a  partial  order  on  S(n),  and  C(n)  is  a  fc-tuple  of  condi¬ 
tions  (ci,  ■  •  • ,  cfc)  where  Var(n)  =  (Vi  :  n,  ■  ■  • ,  Vk  :  n). 
Moreover,  we  assume  that  the  condition  c,  applies  to  val¬ 
ues  of  type  Tj.  Given  a  value  V{  of  type  r,,  we  assume  that 

Vi  |=  Ci. 

A  policy  P  induces  a  partial  order  XP  on  the  instances 
satisfying  P.  Given  an  instance  I,  the  DAG  rooted  at  a  node 
n  of  I  is  called  a  sub-instance,  i.e.,  a  sub-instance  consists 
of  the  node  n  and  all  of  its  descendants.  The  depth  of  a 
sub-instance  is  the  length  of  the  longest  path  from  the  root 
to  one  of  its  leaves.  The  partial  order  Ap  is  defined  on  sub¬ 
instances.  Given  two  sub-instances  Six  =  (Aq ,  Vj ,  rooti ) 
and  SI2  =  (N'2,  V2,  root2),  we  say  that  SI\  Ap  SI2  iff  the 
following  conditions  are  satisfied: 


•  The  roots  are  the  same,  i.e.,  rooti  =  root2. 

•  rooti  is  a  A-node. 

Let  the  set  of  successors  of  rooti  be  {ni,  •  •  ■ ,  «.&}.  Let 
1 1  and  If  (for  1  <  f  <  A:)  be  the  sub-instances  in  SIi 
and  SI2  that  are  rooted  at  nt.  In  this  case  the  condition 
is  that  for  all  1  <  i  <  k,  if  Ap  If. 

•  rooti  is  a  V -node. 

Let  the  successors  of  rooti  and  root2  in  SIi  and  SI2 
be  rii  and  712  respectively,  and  Ini  and  J„2  be  the  sub¬ 
instances  rooted  at  ni  and  712  respectively.  In  this  case, 
the  condition  is  the  following: 

If  ni  =  n 2,  then  Ini  Ap  In2 ;  otherwise, 
ni  A  77,2  in  the  partial  order  pref  (rooti) 
given  by  the  policy  P. 

Notice  that  Ap  is  inductively  defined  using  the  depth  of  the 
sub-instances.  Intuitively,  the  partial  order  AP  extends  the 
partial  order  pref  over  nodes  given  by  the  policy  P  to  sub¬ 
instances. 

Next,  we  extend  the  definition  of  conjunction  of  two 
policies  to  incorporate  preferences.  The  conjunction  of  two 
policies  Pi  =  (Si,  Ci,  pref  1)  and  P2  =  (S2,C2,pref2) 
(denoted  by  Pi  A  P2)  is  a  policy  (S' ,  C’ ,  pref'),  where 

For  each  V-node  n  £  N,S'(n)  =  Si(n)nS2(n), 
pref'(n)  is  equal  to  A1j2,  and  C'(n)  =  (c\  A 
cf,  ■  ■  ■  ,c\Acl),  where  Ci(n)  =  (c\,  ■  ■  ■  ,c\)  and 
C2(n)  =  (ci> ' ' '  >  Cfc). 

Given  n  reconcilable  policies  Pi,  ■  ■  ■ ,  Pn,  an  instance  I 
is  called  a  most  preferred  instance  or  MPI  if  I  |=  (A"=i  A) 
and  I  is  a  maximal  element  in  the  partial  order  induced  by 
the  combined  policy  /\,-L  i  P:- 

3.3.  The  Reconciliation  Algorithm 

Given  n  policies  I\  ,  If,  ■  •  ■ .  Pn,  the  reconciliation  algo¬ 
rithm  proceeds  as  follows: 

First,  we  compute  the  combined  policy 

p  =  AlLt  Ai- 

Next,  starting  from  the  root  the  combined  policy 
P  is  traversed  recursively  to  find  the  most 
preferred  instance  according  to  partial  order  AP 
induced  by  the  combined  policy. 

The  complexity  of  reconciliation  algorithm  is  0(n(\N\  + 
|£j),  where  N  and  E  are  the  nodes  and  edges  in  P.  Details 
of  the  reconciliation  algorithm  can  be  found  in  0T1. 

Assume  that  we  are  given  two  policies  Pi  and  P2  shown 
in  Figures^] and [4]  The  combined  policy  /  j  A  P2  is  shown 
in  Figure  p]  Suppose  that  the  partial  order  on  authentica¬ 
tion  mechanisms  corresponding  to  policies  Pi  and  P2  is 


as  shown  in  Figure  [6]  and  the  partial  order  on  the  encryp¬ 
tion  schemes  corresponding  to  the  policies  Pi  and  P2  is  as 
shown  in  Figure  [7]  The  partial  orders  are  resolved  so  that 
policy  Pi  has  precedence  over  policy  P2.  In  this  case,  the 
partial  orders  on  the  authentication  and  encryption  schemes 
in  the  combined  policy  Pi  A  P2  is  the  one  corresponding 
to  policy  P2,  i.e.,  the  partial  order  labeled  ( b )  in  the  two 
figures.  The  MPI  computed  by  our  algorithm  is  shown  in 
Figure  [8] 

4.  Applications  of  the  policy  reconciliation 
framework 

This  section  illustrates  the  use  of  graphical  policy  in  real 
application  environments.  To  this  end,  we  show  how  our 
policy  reconciliation  framework  can  augment  IPsec’s  exist¬ 
ing  policy  negotiation  and  support  the  Condor  distributed 
computing  system. 

4.1.  Graphical  Policy  in  IPsec 

The  IPsec  Q2  suite  of  protocols  provides  source  au¬ 
thentication,  data  integrity  and  data  confidentiality  at  the 
IP  layer.  These  services  are  implemented  by  the  Authen¬ 
tication  Header  (AH)  and  Encapsulating  Security  Payload 
(ESP)  transforms.  Although  not  a  security  service,  PCP  im¬ 
plements  data  compression.  Each  IPsec  node  (host  or  secu¬ 
rity  gateway)  maintains  a  security  and  compression  policy 
defined  in  terms  of  these  transforms.  Communicating  peers 
establish  one  or  more  pairs  of  policy  instances  (an  instance 
is  represented  as  a  security  association,  or  SA)  by  recon¬ 
ciling  configured  local  policies  (called  proposals).  The  In¬ 
ternet  Key  Exchange  protocol  (IKE)  fl6l  is  used  to,  among 
other  things,  negotiate  this  governing  policy. 

IKE  policy  can  be  modeled  using  our  graphical  ap¬ 
proach.  To  illustrate,  suppose  that  a  host  desires  the  fol¬ 
lowing  policy: 

•  All  outgoing  data  must  be  protected  by  ESP  and  AH 
protocols,  and  must  be  compressed  using  the  PCP  pro¬ 
tocol. 

•  ESP  can  use  3DES,  3IDEA  or  DES  encryption  al¬ 
gorithms,  and  either  HMAC-MD5  or  HMAC-SHA  in¬ 
tegrity/  authentic  ation  algorithms . 

•  AH  can  use  either  HMAC-MD5  or  HMAC-SHA. 

•  PCP  can  use  either  LZS  or  Deflate. 

An  IPsec  proposal  and  graphical  representation  for  the 
example  policy  is  depicted  in  Figure  [9]  The  hierarchi¬ 
cal  DAG  structure  is  clearly  more  expressive  and  efficient, 
i.e.,  one  only  needs  to  understand  the  difference  between 
A  (square)  and  V  (circle)  nodes  to  interpret  policy.  Con¬ 
versely,  one  needs  a  great  deal  of  domain  knowledge  to  in¬ 


terpret  the  proposal/transform  structure  of  IPsec.  Such  intu¬ 
itive  representation  simplifies  specification,  and  ultimately 
reduces  policy  errors. 

Consider  an  extension  to  the  above  policy  that  states  that 
the  use  of  3IDEA  must  use  either  128-bit  or  256-bit  keys. 
In  IPsec,  attributes  such  as  key  length  can  be  specified  only 
once  with  each  transform.  Hence,  a  separate  transform  is 
required  for  each  key  length.  More  generally,  the  number 
of  transforms  grows  exponentially  in  the  number  of  inde¬ 
pendent  attributes.  Conversely,  the  graphical  representation 
only  needs  to  introduce  a  single  subgraph  that  is  shared  by 
the  relevant  nodes. 

4.2.  Hierarchically  Policy  in  the  Condor  system 

The  second  example  of  the  policy  reconciliation  frame¬ 
work  is  used  in  the  context  of  Condor  a  high-throughput 
distributed  system  designed  to  efficiently  schedule  the  us¬ 
age  of  distributed  and  heterogeneous  resources  such  as  idle 
CPU  cycles  and  unused  memory.  Condor  allows  resources 
owners  to  place  various  policy  requirements  on  the  use  of 
their  resources.  Our  hierarchical  DAG  structure  can  suc¬ 
cinctly  encode  Condor  security  policies.  The  design  of  the 
policy  infrastructure  and  its  integration  with  Condor  are  de¬ 
tailed  in  the  following  section. 

5.  Implementation 

We  have  implemented  our  hierarchical  reconciliation  al¬ 
gorithm  in  the  Policy  Reconciliation  Engine  (PRE).  PRE 
reconciles  (only)  pairs  of  XML-encoded  policies.  The  re¬ 
striction  of  PRE  to  two-policy  reconciliation  is  not  a  lim¬ 
itation  of  our  approach,  but  rather  an  artifact  of  the  ini¬ 
tial  target  systems’  point-to-point  communication  models 
(IPSec  and  Condor).  We  will  extend  the  implementation  to 
allow  multi-party  policy  reconciliation  (e.g.,  Ismene  ll23ft. 
DCCM  liTTl)  as  future  needs  dictate. 

PRE  implements  an  asymmetric  requester/responder 
model.  In  this  model,  the  requester  supplies  the  relevant 
policy  to  the  responder.  The  responder  reconciles  the  re¬ 
ceived  policy  with  local  policies  as  needed,  and  the  recon¬ 
ciled  policy  is  returned  to  the  requester.  Both  parties  subse¬ 
quently  use  the  reconciled  policy  to  control  the  session.  We 
chose  a  requester/responder  model  because  it  most  faith¬ 
fully  represents  contemporary  use  of  policy  (e.g.,  IKE  pol¬ 
icy  negotiation  ED)-  This  model  is  similar  to  client/server 
communication  models.  Responders,  acting  as  servers,  gov¬ 
ern  access  to  the  communication  resources  and  requesters, 
acting  as  clients,  submit  requests  for  those  resources.  In 
PRE,  the  responders  assert  authority  over  the  resources  by 
placing  a  higher  preference  on  their  own  (local)  policy. 
Note  that  the  requester  may  (and  often  should)  validate  that 
the  received  reconciled  policy  is  consistent  with  the  origi- 
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nally  proposed  policy.  Policy  validation  interfaces  are  pro¬ 
vided  by  PRE. 

PRE  is  both  a  library  and  a  command  line  tool.  Hence, 
it  can  be  directly  integrated  into  an  application,  or  used  as 
an  external  policy  processor.  Reconciliation  is  a  three-step 
process  in  PRE.  First,  each  security  policy  is  parsed  into 
internal  data  structures.  Then  each  pair  of  policies  is  rec¬ 
onciled  using  the  algorithms  defined  in  section  3.3  Finally, 
the  verification  engine  ascertains  the  correctness  of  the  rec¬ 
onciled  policy  with  respect  to  the  local  security  policy  (i.e., 
implements  the  consistency  test  described  above). 

The  current  implementation  of  PRE  contains  about  1000 
lines  of  C/C++  code.  Source  code  and  documentation  for 
PRE  are  available  for  download. 


5.1.  Integrating  PRE  with  Condor 

Much  of  our  work  in  policy  has  been  motivated  by  the 
requirements  of  the  Condor  system.  As  described  in  Sec¬ 
tion  |4.2[  Condor  schedules  resources  based  on  the  client 
requests  and  other  environmental  factors.  Every  Condor 
peer  has  a  local  security  policy  that  governs  the  services 
providing  the  authenticity,  confidentiality,  and  integrity  of 
the  session  it  supports.  We  have  modified  the  Condor  sys¬ 
tem  to  use  PRE-based  reconciliation  to  construct  the  se¬ 
curity  policy  used  by  each  session.  Past  versions  of  Con¬ 
dor  defined  security  policy  using  flat  structures  called  Clas- 
sAds  f28l.  Class  Ads  flexibly  communicate  resource  ad¬ 
vertisements  and  client  requests.  However,  we  found  the 


structure  of  ClassAds  inherently  limiting,  i.e.,  we  could  not 
represent  the  appropriate  range  of  acceptable  or  preferen¬ 
tial  policies  because  of  their  flat  structure.  Such  statements 
of  policy  are,  as  previously  argued,  hierarchical  in  nature. 
This  need  for  hierarchical  policy  drove  our  efforts,  and  ul¬ 
timately  lead  to  the  development  of  PRE.  For  details  on  the 
implementation,  we  refer  readers  to  ED- 

Currently,  Condor  does  not  authenticate  the  policies  or 
policy  exchanges  beyond  that  supported  by  the  underlying 
transport  layer.  In  general,  how  and  by  whom  policies  are 
issued  and  authenticated  is  an  environmental  and  systems 
design  issue.  Environments  often  require  external  services 
for  storing  and  validation  of  issued  policies  (e.g.,  LDAP  col¬ 
lections  of  signed  policies).  These  issues  are  defined  by  the 
larger  policy  architecture,  and  is  beyond  the  scope  of  the 
current  work.  Interested  readers  are  referred  to  1221  for  a 
taxonomy  of  policy  architectures  addressing  these  issues. 

5.2.  Performance 

Because  of  the  relatively  small  policy  size  and  the  re¬ 
striction  to  pairwise  reconciliation,  we  did  not  anticipate 
the  introduction  of  PRE  into  Condor  would  significantly 
impact  performance.  We  sought  to  measure  these  costs 
through  several  controlled  experiments.  These  experiments 
measured  the  total  execution  time  of  the  policy  negotiation 
protocol  defined  in  the  preceding  section.  All  experiments 
were  executed  in  an  environment  consisting  of  a  single  Cen¬ 
tral  Manager  server  ( 333  Mhz  duo-processor/Linux  RedHat 
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Figure  9.  IPsec  Policy  Example 


7.2)  and  eight  clients  (three  Ultra  10  Sparc  Sun/Solaris  2.8 
and  five  750  MHz  Pentium  III/Linux  Redhat  7.2). 

The  experimental  results  confirmed  our  intuition:  the  av¬ 
erage  protocol  execution  (without  I/O),  for  a  policy  consist¬ 
ing  of  authentication,  integrity  and  secrecy,  only  uses  about 
5.2%  of  the  total  execution  time.  When  including  I/O  over¬ 
head,  the  cost  is  still  small-at  about  10%  of  the  overall  ex¬ 
ecution  time.  Startup  cost  (i.e.  program  initialization)  is 
the  most  dominant  factor  of  the  overall  execution  time,  fol¬ 
lowed  closely  by  overhead  incurred  from  Condor’s  internal 
data  structures. 

5.3.  Future  work 

While  the  theoretical  framework  and  implementation  of 
our  hierarchical  policy  model  have  reached  maturity,  we 
see  further  exploration  of  its  application  to  a  wide  range 
of  problem  domains  as  essential.  Initially,  we  will  seek  to 
integrate  PRE  with  widely  used  policy  systems.  This  will 
enable  us  to  explore  the  ways  of  exploiting  the  PRE  ser¬ 
vices  in  specific  and  policy  reconciliation  in  general.  One 
such  work  will  realize  our  IPsec  policy  in  software.  Integra¬ 
tion  with  tools  such  as  FreeSwan  l27l  will  provide  impor¬ 
tant  data-points  in  the  use  of  extended  policy  services,  and 
serve  to  further  demonstrate  the  power  of  our  approach. 

We  also  seek  to  apply  our  work  to  domains  which  have 
immediate,  but  as  yet  unaddressed,  requirements  for  pol¬ 
icy.  For  example,  reconciliation  may  play  an  important  role 
in  defining  security  for  peer-to-peer  (P2P)  systems.  Cur¬ 
rently,  there  are  few  coherent  security  models  for  P2P.  The 
egalitarian  nature  of  P2P  systems  mandate  autonomy.  Each 
end-point  must  be  able  to  assert  and  realize  a  set  of  secu¬ 
rity  requirements  deemed  important.  However,  autonomy 
must  be  counter-balanced  with  interoperability.  The  collec¬ 


tion  of  participants  must  be  able  to  negotiate  a  shared  view 
of  security.  This  is  precisely  the  definition  of  reconciliation. 
Hence,  we  claim  that  the  fluid  and  heterogeneous  security 
models  of  P2P  systems  would  be  well  served  by  our  work. 
Moreover,  the  clarity  and  succinctness  of  hierarchical  mod¬ 
els  may  enable  more  free  and  open  use  of  security  policies 
in  these  large  communities. 

This  paper  has  discussed  reconciliation  only  in  the  con¬ 
text  of  security  policy.  However,  hierarchical  policy  mod¬ 
els  are  applicable  to  other  problem  domains.  To  illustrate, 
GRID  systems  share  the  resources  in  heterogeneous  envi¬ 
ronments.  Participants  in  the  GRID  have  diverse  policies 
that  govern  the  resource  usage.  Agreement  is  often  achieved 
statically  in  current  GRID  systems  by  mandating  the  adop¬ 
tion  of  a  single  universal  policy.  This  mandate  is  in  di¬ 
rect  conflict  with  the  needs  of  dynamic  environments  whose 
resource  constraints  and  requirements  frequently  change. 
Hence,  policy  reconciliation  systems  such  as  PRE  can  help 
to  bridge  such  a  gap  between  dynamicity  and  the  needs  for 
agreement.  Furthermore,  there  is  often  a  direct  dependence 
between  resource  requirements  and  security  settings  and  dy¬ 
namic  policy  reconciliation  can  act  as  the  agent  between  the 
two.  For  example,  a  system  that  handles  sensitive  data  on 
remote  hosts  will  require  some  minimum  security  policy  be 
enforced. 

6.  Conclusion 

Security  policy  reconciliation  is  the  process  of  resolv¬ 
ing  different  security  policies.  In  this  paper,  we  presented 
a  formal  framework  for  policy  reconciliation.  We  also  pre¬ 
sented  an  efficient  algorithm  for  reconciling  different  poli¬ 
cies.  Two  distinguishing  features  of  our  work  are  hierarchi- 


cal  representation  and  preferences.  We  also  implemented 
a  simplified  version  of  our  algorithm  in  a  software  module 
called  PRE  and  incorporated  it  in  Condor.  Experimental  re¬ 
sults  in  the  context  of  Condor  clearly  demonstrate  that  for 
each  session  the  reconciliation  overhead  is  negligible. 
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